NonSync
Notebooks
electronique
Projets
RCCL_V9b
Documentation
B.Réalisation
1. Multiprocesseur
1.1 Messages
1.2 Programmes
1.2.1 Main
1.2.2 Commun
1.2.3 Flight
1.3 Données
2. Programmes
2.2 Menu LCD
2.2 Menu programme
2.3 Menu UI serveur http
2.3.1 Organisation
2.3.2 Paramètres
3.Sound
4. Télémétrie
dfrobot
PNG
Xon_Xoff
Index

  1. Programmes

Structure des communications

Tâche de base

La communication entre un processeur et son ou ses voisins est organisée par un objet tf3:

  • à 'gauche' une porte série et une limite maximum du code message à envoyer à gauche ( si absent limite =0)
  • à droite une porte série et la limite minimum (si absent = 255)
    Un traitement a créé un message avec le code qui définit le destinataire.
    Une fonction de lecture lit les trois sources (porte gauche , porte droite et file d'attente interne) fournit un message à traiter .
    Si il n'y a rien à traiter, une attente est organisée (asyncio dans le processeur UI )
    Si un processeur reçoit un message qui n'est pas dans la tranche qu'il peut traiter, il le renvoie vers une porte.

A priori on peut regrouper les traitements dans un seul programme qui crée et traite tous les messages (ce sera le 'simulateur').

Tâches dans le processeur UI

Le programme est UI_main.py
Il utilise asyncio pour gérer plusieurs tâches

  • microdot pour le serveur http
  • asyncio pour gérer plus d'une tâche y compris le serveur microdot
    • l'une traite les messages provenant d'un autre processeur,comme ci-dessus . La seule différence est que une 'attente' donne le contrôle à une autre tâche
    • une tâche dicte les messages reçus et mis en file d'attente
    • une tâche communique avec le serveur http et est en fait inactive en vol.

Communication vers le pilote

En condition 'vol'

La communication est par l'oreillette.
Le programme 'calcul' envoie à UI un message code '20', qui comporte une liste de codes 'texte' et de nombres formatés. Ce message est également affiché.

En condition 'sol'

Le message est directement affiché et n'est pas dicté.

Émetteur posé

Ici le pilote tient en main un smartphone, ou utilise le clavier d'un laptop/desktop.

Ecran 'statut'

Cet écran ne permet pas d'interaction, mais le pilote peut choisir un affichage:

  • par défaut : nom du modèle, durée de fonctionnement de l'émetteur et durée de vol; tension ou capacité restante de la batterie
  • par canal, le signal ppm et le déplacement
  • les déplacements de gouverne, affichés selon la configuration:
    - ailerons L er R sur la même ligne
    - volets L et R
    - empennage
    - en croix : deux lignes prof =... et rud ==
    - en V = L et R sur la même ligne
    Parfois l'émetteur envoie un message (dicté en vol) et l'affiche, ceci remplace temporairement l'affichage permanent.

Les commandes du pilote

Commandes de vol

Ce sont tous les entrées analogiques (sticks, curseurs) ou digitales , qui interviennent dans le programme de calcul pour déterminer la position des gouvernes.
Ces organes de commande sont toujours actifs et gérés par le processeur de calcul.

Commandes de trim

Les 4 paires de boutons permettent de régler bien plus de paramètres que simplement les trims.

Commandes menu

Les commandes menu sont les commandes pour l'émetteur. Ce sont les deux boutons du stick droit (DT5), combinées avec l'état du switch strim.

Strim centré = les phases

Ceci décrit mon approche actuelle; une autre approche est possible.
Ceci est géré par le processeur de calcul.
La phase principale est déterminée par le SW4 , à 3 positions, qui définit le rôle du stick M1

  • en haut = avec moteur (M1 = thr)
  • centre = vol normal
  • bas = atterrissage (M1=brake)
    Les sous-phases sont choisies par les boutons de trim du manche et pour le moment sont définies dans le programme du modèle.
Strim en haut= menus démarrage/arrêt

Pour le démarrage: choisir dans une liste de modèles celui qui sera utilisé au prochain démarrage, parmi une liste courte qui a été établie avec le menu complet UI.
Permet un arrêt /redémarrage.
Permet un arrêt sans redémarrage (le redémarrage est ultérieur avec le bouton de power-on BA2 )

Switch en bas = réservé pour menus en cours de vol

J'ai prévu un menu pour choisir parmi quelques quelques affichages d'informations sur le lcd, sans dialogue.

Processeur de calcul

Pico RP2040
Développement avec le boitier V5a voir

  • S_txv5 = lecture brute des DIO ,ADC + affichage LCD
  • ajouter les drivers mcp23Sxx ,mcp3208,st7565
  • Trf est une classe qui gère les communications série, pour des blocs de longueur quelconque
  • C_txv5a = conversion des mesures brutes + LCD
  • config.py fournit la configuration et tout ce qui dépend du processeur (petites différences entre python et micro python).
  • core.py comporte en fait tous les programmes du calcul
  • flight_rs.py comporte mes modules standards pour ma façon de piloter
    Programme principal C_main.
  • lire les DIO/ADC
  • convertir ces mesures brutes en 'hwvars'
  • gérer les changements de phase
  • traiter les boutons de trim
  • exécuter tout le calculs du modèle
  • transférer le résultat vers ppm
  • lire le fichier des paramètres et l'écrire avant l'extinction
    Avec messages:
  • extraire les commandes menu pour traitement par UI
  • traiter les boutons de trim

Modifier des paramètres en vol

voir core.dt
exemple : la ligne du fichier de paramètres
"dt3:c:b": ["Ctx:prof","trim"] .
La clé dt3:c:b est composée de 3 parties:

  • dt3 = la paire de boutons de trim associée au stck 3
  • s5 : le switch s5 est centré (c) . Les trois positions sont a=haut, c=centré,b=bas
  • s4: le switch de phase de vol principale est en bas
    Je donne une signification particulière à s4:
  • au centre: les réglages aérodynamiques tels que différentiel, neutre par phase..
  • en bas : tout ce qui concerne la phase d'attérissage, les freins, la compensation ...
  • en haut : les réglages des organes de commande : course, expo

Ensuite la définition du paramètre qui sera modifié : le "trim" de l'objet "Ctx:prof"
La modification est exécutée par le processeur de calcul en tenant compte de la phase de vol.
Quand il commence à régler un paramètre, le processeur de calcul envoie à UI un message à dicter : le nom de l'objet (tel que "Ctx:prof") et le nom du paramètre (tel que 'trim')... ceci pour éviter de se tromper de paramètre!

Au démarrage (mode sol) il est possible de vérifier rapidement quels sont les paramètres réglables en vol.
En mode 'Émetteur posé' il faut utiliser le smartphone pour attribuer les réglages en vol.

Processeur UI

Pico RP2040 W (avec wifi) complété par un Dfplayer

Dictée

voir 3.Sound

Affichage lcd

cette liste est affichée sur le lcd, un élément par ligne.

Mode de fonctionnement vol/sol/browser

Émetteur en main ,mode vol/sol

Le processeur traite des messages envoyés par le processeur de calcul, les met en forme imprimable , transmet le texte vers le petit lcd et traduit le texte en message dicté.
Tout le traitement de télémétrie

Émetteur posé

Ici le pilote tient en main un smartphone, ou utilise le clavier d'un laptop/desktop.

Choisir entre plusieurs listes - les variables sont dynamiques

  • hwvars
  • variables de calcul
  • choix en plusieurs listes
    • classe-> Objet-> id paramètre
  • affichage du paramètre + choix
    • édition (par exemple pour les valeurs conditionnelles)
    • assignation pour maj en vol
      • vue d'ensemble des dt affectés (0..32)
      • filtre des sw s4 strim
      • choix dt

En entrant dans ce menu, le calcul des positions de gouverne n'est plus transmis et est remplacé par une valeur neutre: 1000 µs pour une voie 'moteur' et 1500 µs pour les servos.
Ensuite le menu permet de choisir un canal et d'enregistrer ou modifier les points.

Simulateur

J'envisage un interface tout à fait séparé et qui utilise un laptop, du moins pour commencer et parce que cette solution est disponible et facile.
L'interface UI utilise PySimpleGUI .
Cet interface comporte plusieurs 'tabs'.
Un des tabs comporte les commandes de l'émetteur:

  • soit la valeur reçue de l'émetteur car il y a une connexion série.
  • soit des valeurs modifiables car il n'y a pas de connexion avec l'émetteur....c'est le simulateur

Sécurité

Un watchdog est disponible:
The WDT is used to restart the system when the application crashes and ends up into a non recoverable state.
https://docs.micropython.org/en/latest/library/machine.WDT.html
Mais attention avec WDT: la liaison avec Thonny est perdue...il reste à effacer toute la mémoire flash pour éliminer les programmes. C'est donc difficile à utiliser en test.
Proposition: un cavalier relie deux pins et inhibe la création du wdt, ou une combinaison de boutons, ce qui permet de se connecter à Thonny.

Plus classiquement , micro-python peut détecter des erreurs (try...) et redémarrer, éventuellement par un machine.soft_reset()